<html>
 <head>
  <meta charset="UTF-8">
 </head>
 <body>
  <h1 data-lake-id="Xc9UY" id="Xc9UY"><span data-lake-id="u159e5b2a" id="u159e5b2a">典型回答</span></h1>
  <p data-lake-id="u315c8527" id="u315c8527"><span data-lake-id="u02841464" id="u02841464">​</span><br></p>
  <p data-lake-id="u4442fc60" id="u4442fc60"><span data-lake-id="u87cf476f" id="u87cf476f">康威定律有各种各样的解读，我觉得比较重要的就是这句话：</span></p>
  <p data-lake-id="u75b41c01" id="u75b41c01"><span data-lake-id="u03d03baf" id="u03d03baf">​</span><br></p>
  <p data-lake-id="uc315f875" id="uc315f875"><span data-lake-id="u99cd8f88" id="u99cd8f88" class="lake-fontsize-11" style="color: rgb(106, 115, 125)">Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)</span></p>
  <p data-lake-id="u97450be3" id="u97450be3"><span data-lake-id="u5f521e39" id="u5f521e39" class="lake-fontsize-11" style="color: rgb(106, 115, 125)">​</span><br></p>
  <p data-lake-id="u92ab4043" id="u92ab4043"><span data-lake-id="uac851371" id="uac851371" class="lake-fontsize-11" style="color: rgb(36, 41, 46)">中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。</span></p>
  <p data-lake-id="ude74afa2" id="ude74afa2"><span data-lake-id="u9075b0a1" id="u9075b0a1" class="lake-fontsize-11" style="color: rgb(36, 41, 46)">​</span><br></p>
  <p data-lake-id="u7242238e" id="u7242238e"><span data-lake-id="u95b0274f" id="u95b0274f" class="lake-fontsize-11" style="color: rgb(36, 41, 46)">看看下面的图片（图片是好几年前的了，但是不重要，足够说明白事情了），再想想Apple的产品、微软的产品设计，就能形象生动的理解这句话。</span></p>
  <p data-lake-id="uab67b429" id="uab67b429"><span data-lake-id="u23f674ef" id="u23f674ef" class="lake-fontsize-11" style="color: rgb(36, 41, 46)">​</span><br></p>
  <p data-lake-id="ua39301fc" id="ua39301fc"><img src="https://cdn.nlark.com/yuque/0/2022/png/5378072/1672143205137-c460f0d2-7af1-4c6b-9272-ce900e29ce24.png?x-oss-process=image%2Fwatermark%2Ctype_d3F5LW1pY3JvaGVp%2Csize_20%2Ctext_SmF2YSA4IEd1IFA%3D%2Ccolor_FFFFFF%2Cshadow_50%2Ct_80%2Cg_se%2Cx_10%2Cy_10"></p>
  <p data-lake-id="u69b64f12" id="u69b64f12"><br></p>
  <p data-lake-id="ubd1d39bf" id="ubd1d39bf"><span data-lake-id="u83ab0f3f" id="u83ab0f3f">简单点说其实就是企业的组织结构决定了业务架构、系统架构。而系统架构的不合理，往往是因为组织架构不合理导致的。</span></p>
  <p data-lake-id="u1c4f150d" id="u1c4f150d"><span data-lake-id="udd292d8f" id="udd292d8f">​</span><br></p>
  <p data-lake-id="u42ec3939" id="u42ec3939"><strong><span data-lake-id="uc04c1695" id="uc04c1695" class="lake-fontsize-12" style="color: rgb(48, 48, 48)">所以很多人说，康威定律如何在半个世纪前就奠定了微服务架构的理论基础</span></strong><span data-lake-id="ud623a380" id="ud623a380" class="lake-fontsize-12" style="color: rgb(48, 48, 48)">​</span></p>
  <p data-lake-id="u26a0cf48" id="u26a0cf48"><span data-lake-id="u404f14c6" id="u404f14c6" class="lake-fontsize-12" style="color: rgb(48, 48, 48)">（1）人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理</span></p>
  <p data-lake-id="uaab9e597" id="uaab9e597"><span data-lake-id="ue0533461" id="ue0533461" class="lake-fontsize-12" style="color: rgb(48, 48, 48)">（2）组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计</span></p>
  <p data-lake-id="u6394addd" id="u6394addd"><span data-lake-id="u77af61fb" id="u77af61fb" class="lake-fontsize-12" style="color: rgb(48, 48, 48)">（3）如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更加高效。</span></p>
  <p data-lake-id="u995afa6b" id="u995afa6b"><span data-lake-id="ua7fe41ab" id="ua7fe41ab" class="lake-fontsize-12" style="color: rgb(48, 48, 48)">（4）复杂得系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的</span></p>
  <p data-lake-id="uf84c535d" id="uf84c535d"><span data-lake-id="ub02de513" id="ub02de513" class="lake-fontsize-12" style="color: rgb(48, 48, 48)">​</span><br></p>
  <p data-lake-id="ud0f871c1" id="ud0f871c1"><strong><span data-lake-id="u29da30b6" id="u29da30b6" class="lake-fontsize-12" style="color: rgb(48, 48, 48)">康威定律的实践建议</span></strong></p>
  <p data-lake-id="u8f5a4009" id="u8f5a4009"><span data-lake-id="u1a1368ea" id="u1a1368ea">（1） 我们要想尽办法来提升沟通效率，比如使用各种工具。能 2 个人讲清楚的事情，就不要拉更多人，每个人每个系统都有明确的分工，出了问题知道马上找谁，避免踢皮球的问题。</span></p>
  <p data-lake-id="u29a45795" id="u29a45795"><span data-lake-id="u49c20341" id="u49c20341">（2） 通过 MVP（</span><span data-lake-id="u4608311e" id="u4608311e">Minimum Viable Product即最小化可行产品</span><span data-lake-id="u5caef435" id="u5caef435">） 的方式来设计系统，通过不断的迭代来验证优化，系统应该是弹性设计的。</span></p>
  <p data-lake-id="u377ccfb5" id="u377ccfb5"><span data-lake-id="u3d646f71" id="u3d646f71">（3） 你想要什么样的系统设计，就架构什么样的团队，能扁平化就扁平化。最好按业务来划分团队，这样能让团队自然的自治内聚，明确的业务边界会减少和外部的沟通成本，每个小团队都对自己的模块的整个生命周期负责，没有边界不清，没有无效的扯皮，inter-operate, not integrate。</span></p>
  <p data-lake-id="ufabc8c35" id="ufabc8c35"><span data-lake-id="u0d8ca902" id="u0d8ca902">（4） 做小而美的团队，人多会带来沟通的成本，让效率下降。亚马逊的 Bezos 有个逗趣的比喻，如果 2 个披萨不够一个团队吃的，那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是 7，8 人左右（包含前后端测试交互用研等，可能身兼数职）。</span></p>
  <p data-lake-id="u33489283" id="u33489283"><br></p>
 </body>
</html>